Diagnostic tools and methodologies are a critical aspect to software and hardware design and facilitate the development of a stable, efficient, and mature computing environment. Diagnostic or “debug” tools are wide ranging, but one common technique is to analyze the state of a computing system's hardware or software to determine whether or not the information possessed by a particular hardware component or logic component is correct.
For example, it may be necessary in diagnosing correct operation of a hardware device to determine whether or not a particular hardware component is operating with the correct flags, values, or states. Such information may be stored via hardware registers or in operational memory. Similarly, a logic module may be diagnosed by analyzing values utilized by the logic module, whether those values are stored in an on-chip cache memory, off chip cache, or in a separate memory module that supports the operation and execution of commands and instructions performed by the logic module.
A common conventional mechanism for obtaining such information from an executing logic module or from a hardware device is to write a specifically targeted instruction that retrieves the required value during an execution loop and then outputs the value to a computer monitor or to a log file. A disadvantage of this approach is that a particular instruction set must be written and executed for every value to be obtained. Moreover, the debug instruction must be introduced to the actual program being diagnosed, or to a custom application which obtains values from the hardware to be diagnosed, and these instructions add additional complexity, execution overhead, and may themselves never be executed if the software or hardware being diagnosed crashes or halts prior to execution of the diagnostic instruction introduced.
Another mechanism for capturing and analyzing state information from an executing hardware device or logic unit is through the use of a logic analyzer. Logic analyzers permit a user to connect “probes” to various hardware connection points, such as Field Programmable Gate Arrays (FPGAs) or to a communication bus, and then monitor signals passing through that location. Software in the logic analyzer then permits the monitored signal to be correlated to certain events, such as a particular state or an instruction passing through that point. Unfortunately, logic analyzers are limited due to the fact that they require the use of “probes” or “clips” that attach physically to the system to be monitored. There are, for example, constraints on the number of probes that may be physically connected to a particular system, and a logic analyzer is further limited as to the number of signal pins it may support, for example, a particular logic analyzer may be limited to 32 distinct signal pin probes, thus limiting the user to selecting only 32 signals to monitor, among potential hundreds or thousands available in a complex system.
Further still, the signal obtained by a logic analyzer must be translated, mapped, or corresponded with a particular event or instruction, and in the process, some detail or information may be lost. Although the logic analyzer has a view of the signals within the system through its “probes,” these signals do not necessarily correspond precisely with the signals traversing the probed location, but rather, they are signals as viewed through the logic analyzer's own hardware and probe lead, which can potentially introduce small differences, or account for the inability to correlate the viewed signal to a precisely corresponding transaction as received by a target device within the system being diagnosed.